MacTech 1 to 12/MacTech-vol-1-12.toast/Tools/MacTCPWatcher-2.0/Eric Behr’s MacTCP Info

Text File | 1996-07-19 | 88KB | 1,588 lines

MacTCP and related Macintosh software

revision 1.4.2, December 1, 1995
------------------------------------------------------------------------
Copyright Eric Behr, Northern Illinois University, Mathematics
Department ([e-mail])
This document can be freely redistributed in whole or in part, provided
that this copyright notice is included intact, and that no material
profit is generated from such a transaction.
------------------------------------------------------------------------
With sincere thanks to:
•Jim Browne -- for his HTML version of the previous revision
•David N. Blank-Edelman, Steve Dorner, Patrick Hoepfner, Peter N. Lewis,
David S. Saunders -- for reviewing the previous revisions
•Adam Engst and Patrick Hoepfner (again!) for extensive comments about
this version
•Mikael Hansen -- for his nagging
as well as to several contributors to Usenet newsgroups, and to all
those who sent me corrections and suggestions (but I'm the sole author
of all mistakes, omissions and inanities).
The newest release of these notes can be obtained by anonymous ftp to
ftp.math.niu.edu (in the directory /pub/mac/doc), or by gopher to
gopher.math.niu.edu (directory "Help Files/Help For Macintosh Users"),
or as http://www.math.niu.edu/~behr/Comp/mactcp.html. The older URL
http://www.math.niu.edu/~behr/docs/mactcp.html will still work for quite
a while but should be avoided. The HTML version is usually updated first
and may be more accurate.
Please send all comments and suggestions to [e-mail].
If you want to make me and my family happy, please send a postcard to

Eric Behr
NIU, Math, WH 320
DeKalb, IL 60115

Thank you!
This page has been accessed 49,115 times (and I only got 69 postcards so
far!  )
------------------------------------------------------------------------

CONTENTS

PREFACE
I. Generalities
II. MacTCP
III. Installation
IV. Configuration
V. Applications
VI. Sources
Appendix A. FTP primer
Appendix B. Elements of Macintosh networking
Appendix C. Dial-in access
Appendix D. MacTCP error codes
Appendix E. Open Transport - first look

------------------------------------------------------------------------

PREFACE

In the past few years the Internet, once an obscure tool used primarily
by academicians, has become a household word. This surge in popularity
created great demand for information about software used to connect to
the "Net", and to navigate its vast expanse.
Macintosh users are blessed with a cornucopia of excellent and
innovative software packages for use with the Internet. Nearly all of
them use the MacTCP driver from Apple.
I've spent many hours installing MacTCP on various Macs. I also devoted
a large part of my free time to digging up various useful applications
for use on the Internet. Hopefully some of my experiences will be
helpful to you.
Please note that I'm not a networking expert. Moreover, in recent months
I have been involved with Macs much less than I used to, so some of my
advice is second-hand.
Those readers who are new to the field of Macintosh networking might get
something out of Appendix B -- please look at it before you continue.
back to table of contents

I. Generalities


I.1. Let's begin with a short sermon

I started using the Internet several years ago, and it has become an
important part of my life - for better or worse. I know that many people
share my feelings about it. For the sake of all of us, please be
considerate! There are lots of things you can mess up if you don't know
what you are doing. Connecting your computer to the network which spans
continents and is used by millions of people in their work is (or at
least should be) a serious act.
Please follow this simple advice:
•when in doubt, don't do anything without consulting your local
knowledgeable system administrator -- chances are that if you don't, you
will break more than you'll fix;
•read newsgroups such as comp.sys.mac.comm, comp.sys.mac.system,
comp.sys.protocols.tcp-ip, comp.protocols.appletalk, especially the
Frequently Asked Questions collections which are posted in most
newsgroups from time to time;
•read the flaming manuals!
•if you are doing something especially tricky, find out how to access
Internet documents (esp. RFC's) and read the relevant ones.

I.2. Where does the Mac fit in?

The Mac has always been a wonderful network machine. But for most people
"Macintosh networking" means Apple's proprietary system called
AppleTalk. The Internet uses a different networking "language". A major
part of it is the protocol known by its acronym TCP/IP. To access the
wonders of the Internet, a computer must understand TCP/IP.
Essentially all network software packages available for the Mac use the
"MacTCP driver" from Apple. Despite its flaws, it provides a uniform
interface to the low-level networking mechanisms, which in the long run
makes life much easier for software developers and end users.

I.3. Various connection methods

The necessary software is only one part of a network connection. The
other, obviously, is suitable hardware. A Macintosh can be connected to
the outside world in many ways:
•with a LocalTalk or PhoneNet connector
•with an Ethernet adapter
•with a Token Ring adapter
•with a modem and suitable software
The first three methods are more reliable and provide higher speeds than
the last one. However, modem connections are becoming more and more
popular.
Macs on Ethernet can usually connect to the outside TCP/IP world without
a problem; for a long time TCP/IP has been the protocol of choice on
Ethernet networks. From the hardware point of view, all that is required
here is an internal Ethernet card, an external SCSI Ethernet adapter, or
-- for Macs with built-in ethernet -- a transceiver with a connector
suitable for your flavor of Ethernet: coax, 10Base-T, or thick.
If you aren't sure which gadget to order, look at the network cables
used throughout your site. Black TV-style cables mean that you need a
coax, or 10Base-2 adapter. Thinner cables with modular plugs (like
telephone ones, only a bit larger) indicate an "unshielded twisted
pair", i.e. 10Base-T installation. Finally, if all you see is a (usually
yellow) cable the thickness of a finger, you may need a special AUI drop
cable which can be plugged into your adapter, and a thick Ethernet
"vampire tap" which needs to be attached to the cable in a specific
spot. In this last case, ask around -- don't do it yourself.
Functionally all three types are identical, and they have nothing to do
with the way MacTCP works.
Macs on LocalTalk can communicate with the outside TCP/IP world only if
the LocalTalk is connected to a larger network using an IP gateway such
as FastPath (Shiva), Gatorbox (Cayman Systems), Multiport Gateway
(Webster Computer Corp.), EtherRoute/TCP (Compatible Systems), or one of
other equivalent devices; or if such a gateway is present elsewhere on
your internet, and is visible to your Mac. For small networks simpler
and cheaper devices or software such as microBridge/TCP or
SuperBridge/TCP from Sonic Systems can be used, even though they are not
full-fledged LocalTalk-to-Ethernet routers.
There are reports of exotic solutions consisting of a PC running public
domain software (PCRoute), with an old Sitka TOPS card, successfully
acting as an IP gateway for a LocalTalk network, but we have not tried
them.
The Apple Internet Router, which is a software package running on a Mac
connected to a LocalTalk and Ethernet networks, can provide TCP/IP
routing between them with the optional IP Gateway module from Apple.
Macs connected directly to Token Ring can speak TCP/IP provided that the
MacTCP Token Ring Extension from Apple is installed along with the main
MacTCP driver.
Software routing of TCP/IP between LocalTalk and Token Ring is now
reportedly possible with products from VICOM. Please note that this is
second-hand information. The PCRoute solution mentioned above might also
be worth exploring here.
Please note that AppleTalk and TCP/IP are two completely different
animals, even though a single Mac can use both at the same time;
configuring AppleTalk functions, such as printing over the network or
AppleShare, will not be discussed here.
back to table of contents

II. MacTCP


II.1. What is it?

For the user, it is a hybrid of a Control Panel and a System Extension;
it is configured just as the Monitors or Sound panels are. For
applications, it is a set of procedures which allows them to communicate
with other hosts on the network using the TCP/IP protocol. It is
designed to be transparent in the sense that once it is properly
configured, any correctly written application can make use of it without
user intervention.
A companion product, AdminTCP, is another Control Panel which lets you
lock certain parameters of MacTCP in place after they have been set. Its
function is to help administrators prevent users from fooling around
with previously entered settings. An average person will not need
AdminTCP (you can get it only by purchasing the full MacTCP kit). It is
also possible that your old AdminTCP (version 1.x) will work with MacTCP
2.0.x, but that has not been extensively tested and may have dire
consequences.

II.2. How to get it?

MacTCP (version 2.0.6 as of this writing) is marketed by APDA (800 282
2732). Some time ago Apple renamed the entire package "TCP Connection
for the Macintosh", which can make it easy for dealers to confuse it
with a commercial product from Intercon Systems, TCP/Connect. We will
continue using the generic name "MacTCP".
There are several ways of obtaining MacTCP:
•check if your institution has a site license (for example, many
universities do)
•buy it from APDA (about $60 list)
•buy it from a mail order Macintosh outlet (at the time of this writing
MacWarehouse has it as catalog # NET0389, $49 + shipping)
•buy a book on the Internet which includes a copy of MacTCP; e.g. Adam
Engst's "Internet Starter Kit for Macintosh, Second Edition" (ISBN
1-56830-111-1) sells for about $25 or less in decent bookstores
•buy the newest System Software from Apple; the currently shipping
System 7.5 includes MacTCP
The last two methods are probably most cost-effective; the only drwaback
is that you don't get the less-than-helpful manual, and a few extra
files (which most users won't need anyway).
If you want to inquire about terms of a site license, send e-mail to
[e-mail].
You might still find a copy of MacTCP floating around the Net, because a
few public domain packages used to include the driver. Beware: those
copies are usually old (e.g. MacTCP 1.1.1), and according to the terms
of the license Apple grants developers, such copies are supposed to be
used only with the application that included them. They are not likely
to work well with newer system software and CPUs, so even if you find
one you may be in for a lot of hassle.
The new implementation of the Mac networking interface, Open Transport,
is currently shipping with some models. For more information about it,
see Appendix E.

II.3. Do I have the newest version?

Even though in some cases you might be able to get away with older
revisions of the software, it is a good idea to get the newest one.
Currently shipping System Software 7.5 includes a copy of MacTCP 2.0.6,
buried among the PowerTalk support files. Even if you don't install 7.5
(or PowerTalk), you can use this driver with earlier releases of the
System. The most widely distributed versions seem to be 2.0.2 and 2.0.4,
which were included with some of the very popular books.
Versions 2.0.2 and 2.0.4 should be patched to 2.0.6 with updaters
distributed on on-line services by Apple (see Part VI for more
information). The updaters only work on original copies of MacTCP. If
you do not have the "virgin" copy, it is possible to modify the
installed one so the updaters will work, but anything involving ResEdit
could be tricky -- do it at your own risk: disable the system heap bit
of the .ipp DRVR resource in the copy you are patching.
back to table of contents

III. Installation

9 times out of 10 MacTCP can be installed simply by copying the relevant
pieces into the System Folder and then configuring them. Still,
non-standard extensions, or corrupted system software might make this
task much more difficult.
My general advice is: start with virginal (or at least freshly updated)
system files. Problems may result from improperly installed old version
of AppleTalk or other resources. For example, I could never painlessly
install new Ethernet drivers on any Mac which previously had some
suspect proprietary network drivers installed on it. What's worse, some
network applications seem to corrupt the System, and/or other important
files, when they crash.
We shall leave those doomsday scenarios for later. In most cases the
following procedure will work. Here we go:
•When MacTCP is being configured, it creates two files: MacTCP DNR and
MacTCP Prep (under System 7 the latter should end up in the Preferences
folder). If you see old copies of those files in your System Folder,
remove them now!
•Since some virus protection utilities might think that the new files
that MacTCP is installing in the System folder are viruses, it is a good
idea to shut off all virus protection before you go any further.
•If the Mac will be used on Ethernet or Token Ring, make sure you have
installed the necessary physical-level network drivers. For Macs with
built-in Ethernet, the drivers are most likely already there. If you are
using a separately purchased network adapter, follow the manufacturer's
instructions.
Apple's Ethernet drivers can be used with Apple adapters and with cards
from certain manufacturers who maintain high degree of compatibility
with Apple (e.g. Asante). Use the newest Apple Network Installer Disk,
which you should be able to get from the local dealer, or from
ftp.info.apple.com. This is particularly important with newer Macs.
•Configure the network drivers, if necessary. Most Ethernet drivers have
no user-changeable settings at all. The Token Ring driver (configured
via its Control Panel) should be set for the correct speed (4 or 16
Mbps). It also lets you set the hardware address of the adapter; if your
site uses locally administered addresses, you need to get one from a
local administrator, and set the driver accordingly.
•If the Mac is to be used with a dial-in connection, install and
configure the relevant extensions and control panels (InterSLIP,
MacSLIP, MacPPP, or similar). Follow the instructions included with the
package. See also Appendix C.
•Put a fresh copy of MacTCP (and AdminTCP, if you have it -- but it
isn't essential) in the System folder. Make sure that you are using the
newest version, and not one obtained from shady sources. Under System
7+, the control panel will go into the proper subfolder automatically if
you drop it on top of the System Folder icon.
back to table of contents

IV. Configuration


IV.1. Variables

The following questions are crucial to the proper configuration of
MacTCP. Try to find the answers to all of them before you begin.
•What physical connection method ("link layer") are you using? Ethernet?
dial-up? LocalTalk?
•Has your Mac been assigned a fixed Internet address, or is it supposed
to be getting its identity from the network? If the former, what is that
address?
•To connect to hosts outside your LAN, MacTCP needs to know the address
of the "default gateway", a device which links your network with the
outside world. Will the Mac be able to discover it on its own (this is
most often the case)? If not, what is its address?
•In order to understand symbolic Internet addresses such as
rs.internic.net, rather than only numeric ones like 198.41.0.5, MacTCP
needs to know about "nameservers", i.e. computers which translate
between the two formats. What is the Internet domain in which the Mac
is? What is the address of the master nameserver for that domain? What
is the address of a nearby major nameserver for the "root domain"?
•Does your LAN use subnetting? If so, what is the "subnet mask"?
Don't worry if the above sounds like black magic. Most of these
questions can be answered by talking to your network administrator. Or
you may have received this information from the Internet service
provider when you bought dial-up access service. In some cases you won't
need all the answers right away.

IV.2. Let's do it!

You should now be ready to configure MacTCP. Open the MacTCP control
panel. You should see a window with one or more icons in the top part,
and a button "More..." in the bottom.
•Click on the appropriate physical layer setting ("Ethernet Built-in",
"LocalTalk", "Token Ring", "InterSLIP", "PPP", etc.) in the MacTCP panel
(if it gives you that choice). If you are using a dial-up connection
such as SLIP, you should have installed and configured the serial line
drivers before. See Appendix C.
Let me reiterate that the physical link setting has little to do with
the network resource (selected in the "Network" CDEV) which you will be
using for AppleTalk functions, such as printing or AppleShare: we're
dealing with strictly TCP/IP stuff.
Newer system software may refuse to load the low-level networking
support at boot time if AppleTalk is disabled, preventing the Mac from
talking to the network adapter. It's safer to keep AppleTalk turned on,
especially when using built-in Ethernet in the newer Macs. This is also
always the case if you are using TCP/IP through the LocalTalk port: you
must have activated AppleTalk in the Chooser -- otherwise that port is
simply dead, and MacTCP doesn't know how to communicate with the outside
world at all.
Here are a few rules-of-thumb for choosing the physical layer: •if you
use LocalTalk, click the "LocalTalk" icon
•if you are on Ethernet, click "Ethernet" (or "Ethernet Built-in" on
older Macs); do not click the "EtherTalk" icon, unless you were
specifically told that you need to use a remote IP gateway
•if you are on Token Ring, click "Token Ring" (you must have installed
the MacTCP Token Ring extension)
•if you are using dial-up connection such as SLIP or PPP, click the icon
of the serial connection driver Now click the "More..." button. You will
see the second level panel of MacTCP (we'll call it the "inner" panel
for brevity).
•Click the appropriate radio button in the "Obtain address" section. If
the administrator assigned a fixed address to your Mac, click
"Manually". In almost all other cases you will use the "Server" setting.
This means that the Mac's network identity will be obtained from a
device such as the IP gateway, a "bootp server", the dial-up SLIP
server, etc. If you use "Server" or "Dynamic" addressing, you should
skip the steps involving the IP address, network class, and subnet mask
-- that information will be determined by MacTCP "on the fly". Use
"Dynamic" addressing only after you've double-checked that this is
indeed what you need. If your network administrator isn't very familiar
with MacTCP, he may mumble "dynamic" over his shoulder even when the
setting should really be "Server", and this misunderstanding may cause
your boss to curse you because her Mac will suddenly stop working.
•If you use "Manual" addressing, you should now click "OK" to go back to
the "outer panel" of MacTCP, and type in the address assigned to the Mac
in the "IP address" edit field. Then click "More..." to get back to the
inner panel.
Please remember that choosing an address at random will at best make
your connections unreliable; it can also provoke unrestrained wrath of
some powerful people in your organization. Courts have been known to
drop bodily harm charges under much weaker extenuating circumstances.
Moreover, some network numbers are illegal on the Internet. If you pick
one of those, you'll be asking for a lot of trouble - in particular,
you'll be getting all e-mail addressed to the University of Mars for the
rest of your life.
In what follows I will use some examples which are real addresses of
real computers on my network; please don't just copy them -- make sure
to change them to ones that are appropriate for your setup!
•The IP number you were assigned determines the network class. MacTCP is
smart enough to figure it out by itself. Addresses beginning with 1-127
are class A, 128-191 indicates class B, and 192-254 are class C. After
setting an address manually, check that the correct network class showed
up.
•You should now set the correct subnet mask. If your network does not
use subnetting, make sure that the "Subnet Mask" slider is in a position
where it can't move further to the left (this is the default setting
that MacTCP uses). If you do use subnetting, slide it to the right so
the correct mask such as 255.255.255.0 will show up above. Do not
experiment here! You must use a valid address and subnet mask, or
somebody will soon come looking for you and your scalp.
•For now leave the "Gateway Address" set to 0.0.0.0; if all goes well,
MacTCP will locate the default gateway by means of a magic wand called
Routing Information Protocol (RIP). If you use "Manual" addressing and
you know that your network does not implement RIP, or you were told by
the manager to use a specific default gateway, you should enter its
address now.
•The last step is to enter the nameserver information. In the first row
of edit fields under "Nameserver Information" enter the domain of your
Mac (e.g. math.niu.edu), the IP address of the nameserver for that
domain, and click the "Default" button. Now go to the next row, type a
single period in the "Domain" field, then enter the same IP address as
in the first row. Do not click "Default" here.
If you were given additional nameserver addresses, or if you wish to use
a backup nameserver for your domain, enter that information in the rows
below. The net result should be something like this:

 -------------------------------------
| math.niu.edu   | 131.156.3.3    | x |  ("default" button on)
 -------------------------------------
| .              | 131.156.3.3    | o |  ("default" button off)
 -------------------------------------
| .              | 131.156.1.11   | o |  ("default" button off)
 -------------------------------------

Close the MacTCP panel.
•Even though MacTCP doesn't always tell you to do so, reboot now! Check
that MacTCP DNR (and usually MacTCP Prep) files show up in the System
folder.
•Test MacTCP by running an application such as TurboGopher or Fetch. If
the software doesn't complain, you should be in business. Try connecting
to a reliable host by opening gopher connection to gopher.micro.umn.edu,
or an ftp connection to ftp.rtfm.mit.edu. Errors such as "connection
refused" are OK; this means that the site is busy. Mac system errors are
bad; consult the list in Appendix D.

IV.3. What can go wrong?

If things aren't working right away, you should concentrate on the
following possibilities:
•bad network or modem connection
•corrupted copy of MacTCP
•bad nameserver information
•bad default gateway setting
•conflict between system extensions
If you are on a network, the best way to check the connection is to make
sure the Mac can see AppleTalk devices such as printers and AppleShare
file servers. Go to the Chooser and enable AppleTalk (you may have to
reboot after that). Then open the "Network" Control Panel and select the
same physical connection as the one MacTCP is using (LocalTalk,
Ethernet, etc.) Finally, go to the Chooser again and check whether your
local printers and file servers show up. If they do, you will at least
know that the wires are OK.
In case of a dial-up connection, you should obviously look at the modem
lights (the "off hook", "receive data" and "transmit data" indicators).
Most serial drivers such as MacPPP also have an icon or some other
indicator showing whether the driver thinks the connection is active,
but this isn't always reliable. You may have to resort to diagnosing the
modem connection with a serial line "sniffer".
Your network or serial drivers may be corrupted, or misconfigured; it
may be necessary to reinstall them from scratch. You may also be using
an incorrect modem init string; Adam Engst's guide on troubleshooting
such problems can be obtain by mailing a request to [e-mail]
.
You can use the MacTCP version of NCSA Telnet to open a connection to a
major site such as rs.internic.net.If Telnet attempts to open a
connection, but nothing happens, you should look at the "Connections"
menu. If it says "XXX is being looked up", chances are that MacTCP isn't
getting responses from the nameservers you gave it. You should try
connecting to a numeric Internet address, e.g. 198.41.0.5.
If Telnet says "XXX is being opened", your Mac may not have the correct
"default gateway" information. Open the MacTCP inner panel and check
whether the 0.0.0.0 gateway setting has changed to something else. If it
didn't, you will have to get the gateway address from the administrator
and enter it manually. If you know the address of a host on your local
network, you can try opening a connection to it; this should succeed
even if the default gateway isn't set properly.
If your application gives a MacTCP "out of memory" error, you may be
running into a problem caused by the interaction between older versions
of MacTCP and a certain new implementations of Unix nameservers. The
problem should be fixed by upgrading to MacTCP 2.0.6.
It may be that some other computer is using your manually assigned IP
address. When MacTCP loads, it in effect says: "host with IP number
so-and-so, please respond". Your Mac's IP address is used in that query.
If there is no answer, all is well. But if something out there responds,
MacTCP correctly assumes that there is a conflict in IP numbers, and
returns an error code which most applications then translate to a
less-than-helpful message like "Error opening TCP drivers - possibly no
dynamic addressing". Talk to the local administrator to verify that the
address you were given is not used by anyone else.
Different applications translate MacTCP error codes into different
messages. Some just display the error number, which isn't very helpful.
See Appendix D for a partial list of those codes, gleaned from the
MacTCP Developer's Kit distributed by Apple.
Much of the above can be diagnosed with a utility MacTCP Watcher,
written by Peter Lewis, and available from most Mac archives.
back to table of contents

IV.4. Drastic measures

If you are still having problems, trash the following from the hard
disk: MacTCP, AdminTCP, MacTCP Prep, and MacTCP DNR. These files are
found in the System Folder proper (in pre-7 Systems) or in various
subfolders, such as Control Panels, Preferences and Extensions. Reboot
and install fresh network drivers, then install MacTCP and configure it
carefully again. Reboot one more time and see if all this helped. If
problems persist, consider trashing not only the MacTCP files, but also
the System, Finder, all network drivers and control panels (AppleTalk,
EtherTalk, Network), and reinstalling fresh copies. This is almost
certainly an overkill, but in some cases it is also a recipe for instant
happiness. Of course, you'd better first back up all the files which see
m important to you, such as non-standard extensions or fonts, which will
get erased in the process! Then install a fresh system.
Disable all system extensions and non-essential network-related Control
Panels, especially those which may be requesting network services at
boot time (such as Network Time). Again, this probably isn't necessary,
but who knows... As is well-known, system extensions can produce
mind-boggling conflicts. When you succeed in making MacTCP work without
them, you should later reinstall them one by one, checking - say -
telnet after activating each of them. If MacTCP conks out, you'll know
the culprit! If that happens, please publicize your findings, or at
least send a note to me.
Remember that in case of a dial-up connection, your Mac is only one
piece of the puzzle. The other end, i.e. your provider's modems, routers
etc. also have to be properly configured, which might not be the case.
Moreover, the provider may be unwilling to admit that something is wrong
-- it's been known to happen. You may have to switch to another one.
Shop around, and stick to the reputable Internet businesses.
If these radical surgeries still don't work, donate your Mac to a local
school, get another one, and begin life afresh.

IV.5. Tricks, hints, and caveats

If you need your Mac's Ethernet hardware address for debugging purposes
or simply for your records, you can get at it by holding option down
while clicking the "Ethernet built-in" icon in the MacTCP panel. Another
method is to log on to a nearby Unix machine, do a "ping" to your Mac's
IP address, and then tell the Unix host to list its "ARP cache": arp -a
on most systems. The hardware address will appear next to your Mac's
name as 12 hex digits divided into pairs. For the ping to succeed you
must first start up some Internet application on the Mac.
Remember that Ethernet and Token Ring handle hardware addresses
differently; if the Unix host and the Mac are on those two different
types on networks, you need to translate each pair of hex digits into 8
binary digits, reverse their order, and translate the whole shebang back
into 12 hex digits to get the real hardware address.
Older Macs, notably the Plus, become overworked while running System 7
(more precisely, the newest versions of AppleTalk) and MacTCP 1.1. Make
sure to install a new version of MacTCP.
Sometimes the physical link icons (usually the "LocalTalk built-in"
icon) mysteriously disappear from the old versions of the MacTCP control
panel. Make sure you are using a current MacTCP.
Don't disregard the physical connection. I've seen several reports of
strange problems which were eventually traced to a bad wire or
transceiver. Some of Apple's "FriendlyNet" cables for use with the
Quadras were involved. Borrow a working transceiver and cable from
someone and try it before blaming everything on the software.
Are things messed up, and you are stuck? Make sure to contact the vendor
of the network adapter. There may be a problem which they know about.
You may need to get an updated driver from them.
It was reported that the Apple cache card (for the IIci) used to cause
problems with MacTCP and a lot of other things. Scream for a
replacement!

IV.6. Using AdminTCP

If you are responsible for configuring MacTCP in your department or
organization, in some cases you will want to lock the settings you have
entered, so that users with itchy hands will not fool around with them.
Open the AdminTCP panel (even an old version should work with a new
MacTCP, but of course it is best to get a current one!) In the inner
panel click the three checkboxes which lock the address, and click the
"Protected" box. Close the panel and reboot right away.
Remember to trash AdminTCP from the user's disk afterwards, so he won't
be able to unlock the settings, unless you trust the user not to mess
things up intentionally.
If the prospective user is a TCP/IP sage, you should of course leave
things wide open for him to play with the little buttons during long
winter nights.
There are some other permutations involving, for example, locking just
the network part of the address, but leaving the subnet and node numbers
accessible. Please read the manual!

IV.7. More about nameservers

Going into the details of the Internet Domain Name System (DNS) would
make this document twice as long, so we will stick with the basics,
explaining what went on when we filled in the MacTCP "Nameserver
information" fields. The Domain Name System is used by computers to
convert the human-friendly names such as "rs.internic.net" to numeric
addresses (IP numbers) such as 198.41.0.5. Internet computers also use
this system to "reverse-map" numeric addresses, i.e. to verify that your
numeric address does correspond to a name which is recognized by the
DNS. A part of MacTCP, the "resolver", is responsible for doing all this
on your Mac.
If your network is connected to the Internet, your computer lives in
some well-defined "domain". In my case, it is math.niu.edu, and a
machine with address 131.156.3.3 is providing name service for that
domain. I thus enter "math.niu.edu" (do not use quotes) in the Domain
field, and 131.156.3.3 in the Server field next to it. I also click the
Default button. This informs MacTCP that my computer is in the
math.niu.edu domain, so when I tell my Mac to telnet to "sunflower", it
will query the nameserver about the address of "sunflower.math.niu.edu".

If the local nameserver doesn't keep a large table of addresses, or if
it is less than reliable, you will probably want to add some backup
servers (this is generally a good idea). In particular, one or more
Domain fields could contain the period alone to handle the "root
domain", i.e. the entire Internet, with the address of a big, reliable
machine next to it.
Clicking the "default" button by no means guarantees that this server
will be consulted first; MacTCP first contacts those nameservers listed
in the control panel which seem to match the domain name included in the
query - and only if that fails, the default server is asked as a last
resort. However, all domain name queries should generally go to your
local nameserver first. You may want to enter your local nameserver's
address in the second row as well, specifying the root domain (period)
in the first field.
If the resolver is given a name without periods in it, e.g. "sunflower",
it will tack on your default domain, and send out a query for
"sunflower.math.niu.edu". If there is no computer by that name, the
query will fail.
If the name contains periods, MacTCP considers it to be a "fully
qualified domain name", and tries to match the tail of it with one of
the domains you entered in the MacTCP panel. For instance, a query for
"sunflower.math.niu.edu" will go to the nameserver specified for domain
math.niu.edu (if any), then -- if that fails -- to the nameserver for
niu.edu (if any), and finally to one of the servers for the root (.)
domain.
There is currently no support for the so-called "partially qualified
names"; e.g. "sunflower.math" will _not_ get anything tacked on, even
though you may hope that MacTCP will be smart enough to try adding
"niu.edu" to it.
A small text file called Hosts can be put in the System Folder proper;
it lets you enter additional information which MacTCP uses when it
carries out the name resolution process described above. For example,

clinch.math.niu.edu      IN   A   131.156.3.3
math.niu.edu             IN   NS  clinch.math.niu.edu
rs6000.cmp.ilstu.edu     IN   A   138.87.1.2
risc                     CNAME    rs6000.cmp.ilstu.edu

in the Hosts file tells MacTCP that clinch.math.niu.edu has address
131.156.3.3, that it is a nameserver for my domain, that
rs6000.cmp.ilstu.edu has address 138.87.1.2; since I connect to it
often, I want my Mac to use rs6000.cmp.ilstu.edu whenever I say "risc."
(if there were no dot, MacTCP would start looking for
rs6000.math.niu.edu!).
A Hosts file on a Mac tends to be neglected or overlooked, unlike -- say
-- the NIS hosts file on your main network server. Keep this in mind
when deciding whether to put a lot of information there. When IP
addresses change, it may come back to haunt you, since you may not even
remember it's there. It's better to rely on a reliable, properly
configured and maintained nameserver for your domain.
A bug in MacTCP 2.0.4 discovered by Sylvia Elliott causes the resolver
to fail on CNAMEs in the Hosts file which contain digits. MacTCP 2.0.6
may have fixed this.
The newest versions of the resolver also disallow host names which
contain underscores. This has caused significant controversy; even
though this is "correct" behavior according to Internet standards, older
implementations have not enforced this restriction, and there are
several computers out there with such names. Until they disappear you
will have to use numeric addresses to reach them.
For a list of specifications allowed in the Hosts file, see the MacTCP
manual.
After modifying the Hosts file or the nameserver information in the
MacTCP control panel, make sure to trash the MacTCP DNR file, and reboot
right away.

IV.8. Minimal setup

It is often useful to construct a minimal network consisting of two Macs
running TCP/IP: either to test an application being written, or just to
see this side of Mac networking in action. Here is what you should do to
get such a mini-net running.
Connect the Macs with a LocalTalk cable (PhoneNet boxes at each end
recommended for good reasons, even though a simple printer cable will do
for those who like risks). Ethernet-ready Macs can be connected with a
short piece of coax cable (good terminators at each end!), or a twisted
pair cable. Do not use a hub-to-adapter cable! it won't work. You have
to swap the send/receive pairs as follows:

  RJ-45 plug pins
   1 -------- 3
   2 -------- 6
   3 -------- 1
   6 -------- 2

On each Mac put a file called Hosts in the System Folder; in each of
them type:

testa     IN   A    244.244.244.1
testb     IN   A    244.244.244.2

Avoid using numbers in host names, i.e. don't try test1 or mac15. And
remember that you have to get official IP addresses before you hook the
Macs up to the outside world.
In MacTCP set the appropriate link icon (LocalTalk or Ethernet),
addressing to manual, gateway to 0.0.0.0, and leave the nameserver
information entirely blank.
In the "outer panel" set the IP address to 244.244.244.1 on one
computer, and to 244.244.244.2 on the other one. Reopen the "inner"
MacTCP panel and verify that subnet mask is 255.255.255.0, and that
network class became C.
Enable AppleTalk in the Chooser, reboot, and you should be up and
running. Install some clients and servers on the Macs (Fetch and FTPd, a
Web client and httpd, and so on) and try them out.
Since MacTCP still has problems with various timing parameters, on a
network like this where delays and transmission times are weird you may
occasionally see errors such as "No connection in place".
As Leo Willems pointed out, a truly minimal configuration consists of a
single Macintosh; for example, a developer may want to test a TCP/IP
client application with a server program running on the same computer.
Set TCP/IP to LocalTalk and manual addressing as above, and don't
connect it to anything! Or, if you want to check Ethernet operation,
plug in a self-terminating Ethernet transceiver and select the Ethernet
icon in MacTCP.
back to table of contents

V. Applications

There are many commercial programs which use TCP/IP connectivity
(InterCon Systems family of networking applications, VersaTerm from
Synergy Software, MacX from Apple, just to name a few). I will not
review them here because I have had little or no experience with them.
Let the vendors speak for themselves.
The list of public domain or shareware software which follows is far
from complete; moreover, new applications appear very often, and we
cannot possibly keep it up to date. We will focus on a few most
important packages which should get you started. See Part VI for
information on obtaining this software.

V.1. Terminal emulation

There are currently two primary free programs which let the Mac connect
to other hosts as a terminal using TCP/IP (telnet): NCSA Telnet and its
derivative, tn3270.
The first one is being developed at the National Center for
Supercomputing Applications in Urbana-Champaign. It emulates a vt100
terminal and provides some Tektronix graphic terminal capabilities; it
also implements an ftp client and server, but support for this will
disappear in future versions.
The second, tn3270 written at Brown University, is a variant of Telnet
which provides the IBM 3270 terminal emulation. It also supports file
transfers and printer sessions, given the right software installed at
the big iron end.
NCSA Telnet used to come in two versions: one which relied on MacTCP,
and one which included built-in TCP/IP drivers. Starting with Telnet
2.5, the two have been merged into a single package.
You may also want to try a third package, Comet from Cornell University,
which is still available from some ftp archives. It can be used over a
network with MacTCP, or with an ordinary modem connection.

V.2. E-mail

There are several schemes in which a Mac can access Internet mail. The
crudest way, of course, is to telnet to a host on which you have an
account, and use that host's mail facilities. Another is to keep using
whatever mail system you have on the AppleTalk network (e.g. QuickMail
or Microsoft Mail), and then provide a SMTP gateway which will translate
it to Internet mail; this tends to be expensive, sometimes unreliable,
and may be difficult to maintain.
By far the most popular and convenient system is the client/server
method, in which one computer uses its powerful mail software and
provides service to clients such as Macs or PCs. Macintosh users have
the good fortune of being able to use some excellent mail clients which
work on a Mac. Eudora written by Steve Dorner leads the pack (in my
humble opinion). Non-commercial versions are still maintained and
supported by Steve, even though innovations and functional improvements
find their way into the commercial package first.
Eudora and other similar clients (such as POPMail II from the University
of Minnesota) allow the user to read, compose, and edit mail on the
Macintosh desktop; it can print mail, save messages as Mac files, and
attach Macintosh-specific files (say, formatted Word documents or even
applications) to the letters using one of the encoding schemes, e.g.
BinHex (see Appendix A). When it's time to process mail, Eudora contacts
the server, uploads messages waiting to be sent and downloads those
which the server received for you. The (supposedly) well-maintained and
well-connected server computer handles the rest, so you don't need to
know anything about Unix or any other alien operating system.
The current versions of Eudora also support MIME (Multi-purpose Internet
Mail Extensions), a standard for transferring images, sounds,
international characters etc. via the ASCII-oriented Internet e-mail.
Seting up a POP server on most Unix computers is rather trivial, but it
does require superuser privileges. If you use a VAX with VMS, and some
TCP/IP package is already installed, chances are that it includes a POP
server. There is also a public domain POP3 server for VMS available from
Indiana University, which a dear friend of mine, a computer
semi-literate, got up and running without much grief. Talk to your local
system administrator.
One of the selling points of the POP protocol is that several decent
clients are also available for DOS and Windows computers (NuPOP,
PC-Eudora from Qualcomm, etc.). Moreover, most of those clients can send
and receive attachments using standard encoding; in many cases it is
possible -- say -- to save a Word document as a WordPerfect DOS file on
your Mac, attach it to a letter in Eudora, and send it to someone who is
stuck with a WordPerfect Office mail system behind a Novell SMTP
gateway...
In case you don't have a bigger machine which may be used as a POP
server, don't worry; your Mac can be made into a full-blown SMTP mailer,
and it then behaves like any other "real" Internet mail node. Glen
Anderson's MailShare does just that, in addition to providing POP
service for other Macs. If all you want is SMTP service for the
individual Mac, you can try Lee Fyock's LeeMail, but MailShare is
probably a better choice at this time. Naturally, a Mac configured as an
independent Internet mail host had better have reliable connectivity
with the world at large (and a properly configured Domain Name
Resolver).

V.3. FTP

Just like Eudora seems to be the mail client of choice, Fetch by Jim
Matthews reigns in the FTP area. Older clients include the HyperFTP
stack, and the orphaned (but still useable) XferIt. There is also an FTP
server that runs on Macs, FTPd by Peter Lewis. Anarchie is a very
convenient marriage of an Archie client (which searches lists of
software on anonymous FTP servers) with an FTP client.
As we will explain in Appendix A most Mac files you download will
require further processing. Fetch allows you to do this painlessly if
you install gadgets such as StuffIt Expander and MacGzip on your disk,
and configure things so that incoming files are automatically
decoded/decompressed by them.
When using FTP from a Mac, you should realize that many anonymous FTP
sites do not allow connections from hosts which are unknown to the
Internet nameservers. To connect to such nodes, your Mac's IP address
has to "reverse-map" to a legal Internet name, like mac1.math.niu.edu.
The system administrator of your nameserver computer might be willing to
enter your address in his database.

V.4. Network news

There are several Mac applications designed to let you access Usenet
news: Newswatcher and Nuntius are probably the most popular. I have not
experimented with Nuntius, so I can only quote second-hand information:
at least one of my correspondents swears by Nuntius as "the best
newsreader I have seen on the Mac by far".
Reading Usenet articles usually involves downloading humongous lists of
articles over a slow connection such as overloaded LocalTalk, or worse
-- a modem link, keeping track of read items, and so on. This is not for
the faint of heart. Many people still stick to the old-fashioned method
of logging on to a bigger host and reading news there. But when it
works, it's worth it! You can finally organize the saved articles on
your own disk, use your favorite word processor to write replies, etc.
News clients require an address of a nearby friendly NNTP server. The
server needs to be friendly in the sense that it must recognize your Mac
as a host which is allowed to post news. As with FTP, this usually
requires having a valid domain name, and the server must have been
configured to accept uploads from your computer. Even though some
servers allow free read access and only limit posting, the Mac clients
will usually give up without explanation unless they are granted both
permissions. This causes a lot of confusion among novice users, who then
complain about "broken newsreaders".

V.5. Internet Gopher

The Internet Gopher is a system of "gopher servers" on various Internet
hosts which can be contacted by a gopher client, passing the connection
on to other servers in a way transparent to the user. The data on the
servers are presented as menus, which can be text or binary files, links
to ftp archives or Usenet news servers, or finally pointers to other
gopher servers. It is a very convenient mechanism for putting the
bewildering spectrum of Internet services under one roof. The principal
Mac client, TurboGopher, has been created by the designers of the gopher
system at the University of Minnesota. There is also a gopher server
which runs on Macs.
Gopher has become one of the standard ways of providing access to
distributed information such as campus directories, WAIS servers,
on-line publications, etc. It is also the preferred method of accessing
many of the anonymous ftp sites, such as the sumex archive at Stanford.

V.6. World-Wide Web

In the 70's FTP was "it". In the early 90's it was the gopher. In
mid-90's, it's WWW, or "W-cubed", or World-Wide Web. Visionaries at the
European CERN laboratory in Geneva realized that hypertext ideas
(conceived quite a long time ago) could be combined with Internet
connectivity to provide a uniform access to resources "out there".
The idea really took off when programmers at NCSA released Mosaic, a
client application which allowed Unix machines, Macs, and PCs to access
WWW servers in a way that showed the stunning capabilities of the
system. After connecting to a WWW "page" you see text, links to other
parts of the document, icons, images, links to other pages thousands of
miles away; you can click on an icon and hear a sound; click on an
underlined address and send a note to someone; click on an electronic
newspaper's masthead and see the editor's face. Access to other
protocols such as FTP or telnet connections is integrated into this
paradigm.
The development of the Web has forced some other standards to evolve
rapidly. The "uniform resource locators", or URLs, are the new language
used to specify where a given item lives in the net universe: e.g.
ftp://ftp.math.niu.edu/pub/mac/doc/mactcp.txt means "connect by FTP to
the host ftp.math.niu.edu, and retrieve the file mactcp.txt in the
directory /pub/mac/doc". Together with MIME, WWW has helped the
evolution of standards for exchanging complex documents between
different systems.
Documents written in the WWW HyperText Markup Language (HTMLs for short)
are very flexible; they can be used to provide a help system for local
users, a tutorial for novice photographers or origami fans, or a
sound-enhanced catalog of music recordings. They are also quite
"expensive" in terms of the network load: WWW pages tend to be full of
images, sounds and icons comprised of hundreds of kilobytes of data,
sometimes causing unprecedented congestion on info-ways we all use. Let
us hope that this will soon cause an equally dramatic increase in the
bandwidth of the Internet infrastructure.
Two Mac clients dominate the field: NCSA Mosaic, and Netscape from
Netscape Communications Corporation. Netscape is a commercial product:
please make sure you read the accompanying license. A third, MacWeb, is
also gaining popularity. You can turn your Mac into a WWW server with a
Mac HTTP daemon application (e.g. httpd or MacHTTP), available from many
archives.

V.7. Miscellaneous gadgets

Many people need to switch between several MacTCP configurations (e.g.
when using a PowerBook at home with PPP and at work with a direct
network link). John Norstad's MacTCP Switcher is a great help in such
situations (note that OpenTransport has the built-in capability to store
various configurations and switch between them without rebooting the
computer).
Even if you install only the basic Internet programs, you will notice
that configuring them all is quite a balancing act. At the same time,
many of them share certain parameters: your name, address of a mail
server, preferred e-mail address, and so on. The program InternetConfig
has been created to help you organize such parameters in one place.
Older versions of these notes listed a number of specialized Mac
applications which use MacTCP in this section. Since this category is so
fluid, with some programs being abandoned, and new ones showing up, I
feel it would be unfair to single out just a few packages I like.
Instead, I will single out one person: Peter Lewis, who has been busy
creating useful MacTCP applications for some time now. They include an
FTP server, a MacTCP debugging application, an intelligent "archie"
client for searching and accessing FTP archives, a "talk" program, and
so on. I feel that Peter's work, which has helped many of us enormously,
deserves special recognition and support.
back to table of contents

VI. Sources

There are some excellent sources of background information on the
Internet in general, and TCP/IP in particular. Two classics which come
to mind are:
"Zen and the Art of Internet" (by Brendan Kehoe),
"Hitchhiker's Guide to the Internet" (by Ed Krol).
Both can be obtained by anonymous FTP from ftp.uu.net (directory
/inet/doc). The files are Unix-compressed, so they should be downloaded
using binary mode and then decoded with a Unix-style uncompress
application. See Appendix A for a primer on ftp. Note that newer
editions of "Zen" are only available commercially.
Several FTP sites have copies of most newer Requests For Comments
(RFCs), documents which establish Internet standards. Try
rs.internic.net or nic.switch.ch. To get started download the files
rfc-index and fyi-index. There is no substitute for reading RFCs
(painful as it may be...)
A popular and very complete paper reference is "The Whole Internet
User's Guide and Catalog", also by Ed Krol, published by O'Reilly and
Associates.
A three-volume series "Internetworking with TCP/IP" by Douglas Comer is
published by Prentice Hall, and contains everything you have ever wanted
to know about the protocol that makes the Net tick.
Frequently Asked Questions (FAQ) files are the accepted method of
answering "newbie" questions; even if you consider yourself an
experienced 'Netter, you may want to check them out. The most relevant
one is available by FTP from rtfm.mit.edu, in the directory
/pub/usenet-by-hierarchy/comp/sys/mac/comm.
The main archive of public domain and shareware Mac software is on
sumex.stanford.edu. There are several "mirrors" which you may want to
try when sumex is too busy to let you in, e.g. nic.switch.ch or
src.doc.ic.ac.uk, but they are often just as busy as sumex. Another
fairly complete Mac archive is on mac.archive.umich.edu.
Adam Engst keeps a comprehensive collection of Mac communications
software on ftp.tidbits.com, in the directories /pub/tidbits/tisk and
/pub/tidbits/select. For announcements of new versions of this software,
WWW users should see http://www.mcp.com/hayden/iskm/. If you are looking
for a communications package, or an init string for your modem, or a
SLIP dialup script, those are the places to look. You can also send mail
to [e-mail] to inquire about the current status of his "Internet
Starter Kit" book.
Official MacTCP-related files released by Apple can be obtained by
anonymous ftp from ftp.info.apple.com and from seeding.apple.com; Web
fans can try http://www.info.apple.com.
Note that Apple likes to distribute some of its software as "disk image"
files. Such files have to be loaded into an application such as DiskCopy
(available on ftp.info.apple.com in /dts/utils) or ShrinkWrap, which can
then produce exact copies of an original master floppy disk. Moreover,
many files on Apple archives are prefixed with the lengthy lawyer-speak
section, which can justifiably confuse some BinHex decoders; after
downloading such .hqx files, use an editor to cut out the legalese
before de-BinHexing.
Here are pointers to software which is found in less obvious places:
Eudora: ftp.qualcomm.com
GopherApp: ftp.bio.indiana.edu in /util/gopher/gopherapp
MacDump: bbn.com in /pub/MacDump
NetNews: ftp.bio.indiana.edu in /util/mac
Netscape: ftp.mcom.com
POP servers: ftp.qualcomm.com, ftp.cc.berkeley.edu
tn3270: brownvm.brown.edu
TurboGopher: boombox.micro.umn.edu in /pub/gopher
VMS POP server: ftp.indiana.edu in pub/vms/iupop3
This should keep you busy for now...
back to table of contents

Appendix A. An FTP Primer


A.1. Downloading text files

Use any account available to you on a well-connected host. Type "ftp
ftp.math.niu.edu". When asked for a username, reply "anonymous"; give
your mail address as password. In 9 cases out of 10, archives such as
this one will accept "ftp" in place of "anonymous", which is meant as a
favor to the new spelling-challenged generation. You will also discover
that many sites will accept any password at all, but let's be nice to
those folks who specifically ask for the real id.
Enter "cd /pub/mac/doc", and then "get ftp-primer.txt". When you see
"Transfer complete", type "quit" and read the file you just downloaded.
After becoming skilled in using ftp, download some more text files from
the /pub/mac/doc directory on ftp.math.niu.edu:
help/accessing-files.txt
report/how-do-i-find.txt
Many more such files are on sumex.stanford.edu, in the directory
/info-mac/comm/info (most of them are mirrored on ftp.tidbits.com in
/pub/tidbits/tisk/info). See Part VI for details.
WARNING!!! The minute you start downloading files from the network, you
become more susceptible to viral infection than before. I strongly
suggest that you should first get and set up the wonderful free virus
checker, Disinfectant. Its home is ftp.acns.nwu.edu, in directory
/pub/disinfectant; it can also be found in many other places, e.g. on
sumex.stanford edu in the directory /info-mac/virus. You may then want
to send its author, John Norstad, a nice thank-you note: we all owe him
a great deal! If you have access to Usenet news, make it a habit to
monitor the comp.sys.mac.announce group: it is probably the most
reliable source of information about newly discovered viruses.

A.2. Peculiarities of Mac file transfers

Macintosh files differ from files on most other machines in that they
consist of two parts. One contains data (text, executable program), and
the other - resources (icons, the file's creator code, etc.) I'm
simplifying a little, but never mind. This complicated structure
prevents us from sharing such files directly over the network.
Moreover, there is only one language which practically all computers
understand: the ASCII code (plain text). Even though this isn't a
terribly elegant solution, we simply bring everything to this lowest
common denominator to assure compatibility. For example, in order to
send a file to someone by the current e-mail systems, it has to be
somehow encoded into an ASCII file.
The Mac community has pretty much agreed on a common standard for doing
just that: BinHex. BinHex swallows a Mac file, icons, file creators and
all, and converts all that into a plain text file filled with something
that looks like garbage; it also performs the reverse procedure. So you
need BinHex.
There is one obvious difficulty, however: how do you get a BinHex
decoder (a Macintosh application!), when you don't have BinHex? You will
also need software which will somehow let your Mac do FTP. The easiest
way to "bootstrap" yourself is to simply get a copy of such a beast from
a local Mac guru or a Mac User Group. If you're lucky, you will lay your
hands on a utility which can not only transfer files, but also un-BinHex
them -- such as Fetch, or TurboGopher. You can then tell it to connect
directly to, say, sumex, dowload the interesting BinHex'ed files, and
decode them while they arrive.
Another way is to get NCSA Telnet, log on to a friendly Internet
machine, download the applications you need to that computer in *binary*
form (e.g. the file binhex4.bin available on sumex in /info-mac/util)
using the binary mode in ftp. Then connect back to your Mac using the
Telnet FTP server and put the files on the Mac using the MacBinary
mode... It sounds (and is) a bit complicated, but remember - this
convoluted process is necessary only in the very beginning.
Once again, we have just licked the surface of this topic here. For more
information, see the file /info-mac/report/ftp-primer.txt mentioned in
Part VI.

A.3. What next?

When you have learned how to download Macintosh executable files, it's
time to go hunting for specific applications. Use the hints given above
to "bootstrap" yourself. The possibilities under your fingertips are
something that your parents didn't even dream about.
You may want to start experimenting with Gopher, and WWW at this point.
Most software available via FTP can also be downloaded using those
tools, which often let you find things more quickly and easily. We have
already mentioned another application, Anarchie, which is invaluable in
locating hard-to-find files on FTP servers.

A.4. Let's end with a short sermon...

Many of the applications mentioned above are NOT in public domain. They
are either shareware, or there are restrictions on their use and/or
distribution. PLEASE PAY FOR SHAREWARE YOU KEEP!!! Author's address can
almost always be found by pulling down the Apple menu and selecting
"About..." Let's keep this wonderful, affordable software alive!
back to table of contents

Appendix B. Mac networking: mini-tour

In the networking world, it is easy to drown in the alphabet soup and
the sea of obscure terms. But understanding the process by which
computers communicate helps troubleshoot problems. We will go through
some elementary information in this appendix. Things may get a bit
confusing, and you may want to read what follows two or three times
until it makes sense...
For two digital devices to talk to each other, there must be a physical
connection between them (a wire, optical fiber, radio link, etc.) and an
agreement as to the logical organization of the information. In
computerese, such mutual understanding is usually called a
"communications protocol".
Apple's Macintoshes use a "native" set of protocols, collectively known
as AppleTalk. The physical aspect of AppleTalk is, very simply, the kind
of wires the device uses. If you stick a little round connector into the
printer port of your Mac, or in the jack in your LaserWriter, you are
using AppleTalk over Apple's original slow wiring, i.e. LocalTalk.
Almost nobody uses that now -- even Apple's own network uses Farallon's
Phonenet system, but that is a technical detail. You are on LocalTalk.
If your Mac has an Ethernet card or external adapter attached, you will
be using AppleTalk on a physical Ethernet network; that is called
EtherTalk. Similarly, if you install a Token Ring adapter, the
incarnation of the AppleTalk protocol you are dealing with is called
TokenTalk.
The logical layer of AppleTalk handles details such as how two Macs can
discover each other on the network, how individual nodes are uniquely
identified, what should a Mac say to a printer or an AppleShare file
server when it wants to use it, and so on. The devices you see in the
Chooser (LaserWriters, file servers, or routers such as Netway or
SNA/ps) are all AppleTalk devices. The beauty of AppleTalk is that you
don't really care what physical method you use. You may see a printer on
LocalTalk, or a LaserWriter IIg on Ethernet, or a Netway box on Token
Ring -- it doesn't matter.
But the nitty-gritty of how the actual network operates does vary from
one kind of wire to another. The computer has to behave differently on
each kind of network, but of course you don't want to know about that!
Enter "network drivers": low-level pieces of system software which take
care of that. When you put in an Ethernet card, you need to install the
EtherTalk drivers in your system. Same with TokenTalk drivers. It's like
speaking with someone over the phone, or on a walkie-talkie. The
principle is different, but the message is the same.
There are more and more ways of making non-Apple devices speak
AppleTalk: that's why there are MS DOS computers on LocalTalk networks,
Novell AppleShare servers, and you can configure your Sun Sparcstation
to print on an Apple LaserWriter. The Internet world, however, doesn't
know the first thing about AppleTalk. It only understands the collection
of protocols known as TCP/IP. What does TCP/IP have to do with
AppleTalk? The answer is "not much", and "nothing" most of the time.
Putting a Mac on a TCP/IP network is like dumping an Englishman in the
center of Beijing: there is a language barrier.
MacTCP, the gadget we are discussing in this document, allows Mac
applications to use network interfaces -- such as the built-in LocalTalk
port or an Ethernet card -- to transmit and receive data packets which
contain TCP/IP information, and hence to communicate with the millions
of other TCP/IP computers on this planet.
Just like Apple came up with specifications for sending the high-level
(AppleTalk) data using the various low-level, network-specific
"transport protocols" (Ethernet, Token Ring etc.), the Internet has
standards for sending the high-level TCP/IP data using the low-level
network mechanisms. Ethernet is the best choice, since the Internet
protocols reached their maturity on Ethernet, so those standards are
well-established.
Apple adopted a certain way of sending TCP/IP data wrapped inside
LocalTalk packets, and MacTCP knows how to handle this. It puts
("encapsulates") TCP/IP information into a normal LocalTalk packet, and
sends it out. That packet makes absolutely no sense to any AppleTalk
device (it looks like it has garbage inside), except those which use
MacTCP to do the reverse decoding.
A standard for transmitting TCP/IP data in Token Ring packets has also
existed for quite some time. But MacTCP did not know about it, until
Apple released an add-on "MacTCP Token Ring Extension", which -- again
-- takes a TCP/IP packet and beats it into shape before sending it
through a Token Ring card.
To make things more interesting, MacTCP used on Ethernet (or Token Ring)
is capable of two different behaviors: it can take the TCP/IP data and
spit it out unadorned, according to the usual, world-savvy
IP-on-Ethernet or IP-on-Token Ring recipe. But it can also be set to use
EtherTalk (respectively, TokenTalk), which means that it will activate
the wrapping/unwrapping AppleTalk filter between the network interface
and the application software! The general idea is not to use EtherTalk
or TokenTalk in MacTCP. The reason should become clear soon.
To summarize, here are some scenarios. (a) Mac on Ethernet, MacTCP
correctly installed, "Ethernet built-in" set in the MacTCP control
panel; (b) Mac on Token Ring, MacTCP installed, the Token Ring driver
installed and configured properly, Token Ring selected in MacTCP. All is
peachy. A TCP/IP-aware application on the Mac (such as NCSA Telnet, etc.
-- see Part V) wants to communicate with a Cray at the Space Station
"Alpha", which by the time I finish this might be in orbit. It tells
MacTCP to send out a Telnet packet, MacTCP translates it into the
standard format for Ethernet or Token Ring, some gateways down the road
convert it to the TCP/IP over radio waves form, the packets gets to the
Cray, it says "Aha! we've got a hacker trying to log in here", and so it
goes.
Now for something more mundane. (c) Mac Plus on LocalTalk, MacTCP
installed, "LocalTalk built-in" selected in the MacTCP panel (the only
possible choice!). A TCP/IP "datagram" goes out after being wrapped into
an AppleTalk packet! Now, the LocalTalk is no doubt connected to the
outside world one way or another. If that's done using a relatively
unsophisticated device, it will take the data and simply convert it to
an equivalent EtherTalk, TokenTalk, or whatever packet. That one goes
out allright, gets up to the Cray, but it now says: "Phooey, that's
something I don't understand! It has some strange stuff inside! Let's
quickly drop it on the floor." The reason is that most Internet hosts,
like our Cray, are not instructed by their software to go deeper inside
the packet and actually recognize that it was TCP/IP information wrapped
inside AppleTalk... and why should they bother? What is needed is a more
sophisticated gateway between the LocalTalk and the outside network.
Scenario (d): Mac Plus on LocalTalk sends a TCP/IP-in-AppleTalk packet
which is directed towards a "DDP-IP gateway", such as the Fastpath,
Gatorbox, EtherRoute/TCP, etc. The gateway's software is smart enough to
look under covers and see what is hiding inside. If it sees TCP/IP data
wrapped inside AppleTalk, it strips the outer layer and passes the raw
IP information in the standard format to the Ethernet network. All is
well again! LocalTalk-to-Ethernet gateways like that are common, but
equivalent ones for Token Ring are still scarce and expensive.
How about (e): just like in scenarios (a) or (b), except MacTCP is set
to use EtherTalk (or TokenTalk). Now regular TCP/IP packets will not be
coming through -- MacTCP simply ignores them! It expects AppleTalk
packets only. It will be able to communicate with the Mac Plus in (c),
but not much else. So let's just forget it and stop here...
back to table of contents

Appendix C. Dial-in access


C.1. ARA

In our personal opinion, the most elegant way to connect a Mac to a
TCP/IP network is AppleTalk Remote Access (ARA), a commercial product of
Apple Computer, bundled with PowerBooks, and sold as a separate product.
ARA uses the Communications Toolbox (built into System 7, and
installable in System 6.0.x) to ship AppleTalk packets over a modem to
an ARA server, which is presumably connected to a "real" network. MacTCP
in turn uses the AppleTalk protocol to transmit "wrapped" TCP/IP packets
(if it is configured to communicate via AppleTalk). This results in a
two-stage translation: TCP/IP-to-AppleTalk, and AppleTalk-to-modem. The
data have to be decoded by a reverse process at the other end. This
explains the only major drawback of ARA: speed. A 2400 baud modem is
 next to unusable in this configuration. But a 9600 baud or faster
connection provides decent response even with the additional IP
encapsulation. The server Mac, whether it's on Ethernet or LocalTalk,
spews out AppleTalk packets, from which the TCP/IP information has to be
reconstructed by an IP gateway. If you don't have a gateway such as the
Fastpath, GatorBox, EtherRoute, or similar, you can't use ARA for TCP/IP
access to the network.

C.2. SLIP and PPP

The most popular dial-in connection schemes, however, employ protocols
developed specifically for that purpose, such as SLIP or PPP. A public
domain MacPPP driver is available from several Mac archives, and is
quite serviceable. There are also commercial PPP drivers. SLIP is
available on the Mac in the form of several commercial offerings. More
information on SLIP software can be found on ftp.bio.indiana.edu in the
directory /util/slip. Pat Hoepfner also suggests reading two documents
at "ftp.uu.net" in the "vendor/MorningStar/papers" directory. These unix
compressed PostScript files are named "sug91-cheapIP.ps.Z" and
"ppp-white-paper.ps.Z".
A suitably configured SLIP connection gives the dial-in Macintosh all
the functionality of a node attached directly to a TCP/IP network, even
though it is of course usually much slower, even with the modern 28,800
bps modems. Configuring reliable dial-up connection is not a trivial
matter, because the modem and the SLIP or PPP software add a new layer
of complexity. One universal rule seems to be that with fast modems you
have to: (a) use a "hardware handshaking" modem cable; (b) set your
software so it uses hardware (CTS or RTS & CTS) handshaking; and (c)
initialize the modem so it has XON/XOFF handshaking disabled.
In most cases you will set MacTCP to server addressing when using serial
line connections (unless your provider only supports static address
assignment). Most of the MacTCP parameters (gateway, subnet mask, etc.)
are either irrelevant here, or will be set by the SLIP or PPP driver at
connection time.
Let's now look at two most popular serial IP drivers for the Mac: MacPPP
and InterSLIP. They are both freely accessible from on-line sources. I
don't know much about modems, and I use SLIP and PPP only occasionally,
so the sections that follow are not likely to help you troubleshoot
difficult problems. Adam Engst's book mentioned in Part II has much more
information on the subject. You can also receive some help by sending an
e-mail note to [e-mail].
If you are having problems with sending longer messages via Eudora over
a dial-up connection, you may want to fill out a report to help track
down the cause.

C.3. InterSlip

Start up InterSLIP Setup. Create a new setup using the File menu.
Double-click on it to open it. Set the modem parameters, remember about
hardware handshaking. Opening InterSLIP Setup will have created a folder
InterSLIP Folder:Gateway Scripts inside the Preferences Folder in the
System Folder. Create your connection script, which is a text file (see
simple example below), and put it in that folder. You should now be able
to select that file in the Gateway setting in InterSLIP Setup.
You can now set other parameters. I have the nameserver entered manually
in InterSLIP, RFC compression on, hardware handshake, Hayes-Compatible
modem (I use an AT&T Dataport 14.4). IP address and MTU Size are empty;
they will be obtained from the SLIP server at connection time. Username
and password will have to be set to values you were given by the SLIP
administrators, or left blank if the server does not require them.
Here is a simple connection script which should work with a server that
doesn't do user authentication. Most real-life situations will call for
a more complex one.

!
@originate
note "Waiting for prompt"
matchclr
! edit this to match the prompt your server gives
matchstr 1 4 "TSERVER>"
matchread 50
note "Gateway not responding!"
exit -1
!
@label 99
pause 1
sound
pause 60
exit -1
!
@label 4
note "Requesting SLIP"
write "slip\13"
matchstr 1 5 "Entering SLIP mode."
matchread 120
note "Cannot invoke SLIP mode"
jump 99
!
@label 5
matchexp 1 6
"[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*\\.[0-9][0-9]*\\."
matchread 120
note "No IP address given"
jump 99
!
@label 6
setip "^0"
matchclr
matchexp 1 7 "[0-9][0-9]*"
matchread 120
note "No MTU value"
jump 99
!
@label 7
setmtu "^0"
exit 0


C.4. MacPPP

If you have access to a PPP server, you may want to try the freely
available MacPPP driver from Merit and University of Michigan. It is
available on most Mac archives, e.g. on ftp.tidbits.com in
/pub/tidbits/tisk/tcp. Rather complete documentation available from the
same sources. As with InterSLIP, it is crucial to get the handshaking
settings straight.
Instead of a script, MacPPP uses a set of edit fields in which you enter
the strings to wait for, and responses to send in order to negotiate
connection parameters. In the simplest scenario you would simply tell
MacPPP to wait for your server's prompt, and then send a command
requesting PPP mode. It is easy to make a mistake here, forget to end
the response with a carriage return, etc.
To see what your server sends during connection attempts, and to
experiment with the responses it may expect, you can simply dial into it
using a plain-vanilla terminal emulation package, e.g. ZTerm, and jot
down what happens on the screen.
Even though MacPPP can be set to close the connection after a specified
period of inactivity, it will perform only a "soft close", and will
later periodically try to reestablish it. This can dramatically alter
your next phone bill... Remember to use the "Hard Close" button to
terminate a PPP session.

C.5. Multiple Macs with dialup

One of the most frequently asked questions comes from users who have
purchased a SLIP or PPP account from their service provider, but would
want a small home or business network to take advantage of that single
Internet entry point.
After the Mac connected to the modem establishes a serial line link, one
would need to connect the other computers to its network port (LocalTalk
or Ethernet), and have MacTCP route packets between the two ports on an
"as-needed" basis. This is non-trivial, and can only be accomplished
with special software.
One possibility which has existed for quite some time is to use a Unix
variant which runs on a Mac and has this capability -- e.g. Mach from
Tenon Intersystems, which runs on virtually any Mac and allows such
routing. Another possibility is to use a PC running Linux, which can
also be configured to provide the routing function. This, however, means
getting involved in Unix administration, which is not for the faint of
heart.
A better alternative might be the recently released family of software
routers for the Mac from VICOM. Some of them can apparently be used for
the purpose described above. Note that I have not tried any of them, and
that there might be competing products that I'm not aware of.
back to table of contents

Appendix D. MacTCP error codes

Please note: the information in this section is in no way blessed or
authorized by Apple Computer, Inc. It is simply a summary of information
contained in publicly available header files related to MacTCP (those
are Copyright: (C) 1984-1994 by Apple Computer, Inc.) The list is not
necessarily accurate nor up to date.

-23000    bad network configuration
-23001    bad IP configuration error
-23002    missing IP or LAP configuration error
-23003    error in MacTCP load
-23004    error in getting address
-23005    connection is closing
-23006    invalid length (of what??)
-23007    request conflicts with existing connection
-23008    connection does not exist
-23009    insufficient resources to perform request
-23010    invalid stream pointer
-23011    stream already open
-23012    connectionTerminated
-23013    invalidBufPtr
-23014    invalidRDS
-23014    invalidWDS
-23015    openFailed
-23016    commandTimeout
-23017    duplicateSocket

-23032    Packet too large to send w/o fragmenting
-23033    destination not responding
-23035    ICMP echo timed-out
-23036    no memory to send fragmented pkt
-23037    can't route packet off-net

-23041    nameSyntaxErr
-23042    cacheFault *
-23043    noResultProc
-23044    noNameServer
-23045    authNameErr
-23046    noAnsErr
-23047    dnrErr
-23048    outOfMemory


back to table of contents

Appendix E. Open Transport - first look

Apple's new implementation of the networking interface, Open Transport,
is scheduled to become an integral part of the next major version of the
operating system ("Copland"). Early versions are currently included in
System 7.5 being shipped with the models which use the PCI bus. Open
Transport is an "umbrella" which integrates the various protocols a Mac
can use to communicate with other network devices. It now includes
AppleTalk and TCP/IP, with support for others (serial protocols, Novell
IPX) to be added in the near future.
At this time we can only offer a cursory description of the current
release. The software is still under active development, so some of our
observations may not apply to future versions.

E.1. Do I need it?

Most likely not, if you have MacTCP up and running. At this time the
only "official" way to get Open Transport is to buy a PCI-based Mac, or
to obtain a copy through Apple's beta testing or early evaluation
program. OT is not supposed to be installed on computers which do not
require it. However, we took the risk of putting it on an SE/30 running
System 7.0.1, and on a PowerBook 520 under 7.5, both with a direct
Ethernet connection.
Even though in my case there were no apparent problems, and the new
features are certainly tempting, you have to think twice before trying
OT on your Mac: there have been many reports of serious trouble, in
particular with serial drivers such as MacSLIP.

E.2. New features

Open Transport TCP/IP implementation is more modern than the old MacTCP
code. The four main differences that should be apparent to an average
user are: cleaner user interface; performance improvements; the ability
to specify several domains to search; and the ability to switch between
configurations without restarting the computer. In the next section you
will see statements such as: press the "Select Hosts File" to select the
Hosts file"... This is the best illustration of the fact that the
interface has improved quite a bit. It is almost self-explanatory, with
various fields and menus doing precisely what the labels say they should
be doing. What a relief!

E.3. Installation and configuration

The OT Installer adds several control panels and extensions. Before
running it, back up MacTCP and AdminTCP, and make sure you have a floppy
from which you can reinstall the Network control panel and extension if
necessary.
The two new control panels, AppleTalk and TCP/IP, are roughly the
equivalents of the old Network and MacTCP panels. We will concentrate on
TCP/IP only.
Open the TCP/IP panel. The Edit menu contains an item "User Modes..."
which determines the amount of detail you are shown: Basic, Advanced,
and Administration (the equivalent of AdminTCP). The last one lets you
set a password needed to get into that mode. For now, select Advanced.
The first pop-up menu, labeled "Connect via:", contains the choices
"Ethernet" and "AppleTalk (MacIP)". The latter should be used when you
need to encapsulate TCP/IP packets in AppleTalk, as mentioned in
Appendix B. More choices will show up if you have other network drivers
installed (Token Ring, MacPPP, etc.)
In the next pop-up menu you select the configuration method. In addition
to "Manual", in case of Ethernet or a serial link there are three other
choices: BootP, RARP, and DHCP. All three require some sort of server
from which the Mac will obtain its TCP/IP settings. Apple documents
mention that selected serial drivers (MacSLIP, InterSLIP, MacPPP) have
been tested with BootP, which is roughly equivalent to the old "Server"
setting in MacTCP. They also indicate, however, that when using a PPP
server which will provide an Internet address for the Mac, "Manual"
configuration should be used; the PPP server will then overwrite the IP
address entered below. We have not had a chance to try Open Transport
with any serial protocol yet.
DHCP is a versatile, standard method of administering settings for a
large number of hosts. This is the method of choice for network managers
who are tired of chasing down address conflicts and other problems. DHCP
servers run under most mainstream flavors of Unix, under Windows NT, and
so on.
When the connection is to be made via AppleTalk, one of the
configuration methods that shows up is "MacIP server"; this requires a
gateway (such as an Ethernet/LocalTalk router) which will assign an IP
address to the Mac.
The "Select Hosts File..." button lets you point OT towards a file
containing addresses and aliases of hosts, but this is discouraged as a
potential source of problems in administering many computers. It's
better to rely on nameservers, especially since the Hosts file has been
traditionally used to circumvent shortcomings in the MacTCP name
resolver -- and those have largely been removed in the Open Transport
implementation.
To finish manual installation you need the same information as indicated
in Part IV. Enter the numeric Internet address of the Mac in the "IP
Address:" edit field. The default domain (e.g. math.niu.edu) goes in the
"Domain name:" field. Decimal value of the subnet mask (e.g.
255.255.255.0) should be entered in the next field.
The "Router address:" field can contain numeric addresses of one or more
routers which connect the local network to the rest of the world. The
software will detect failures in contacting any one of them, and try the
next one, etc. Similarly, the "Name server addr:" field should contain
at least one numeric address of a reliable local nameserver.
One of the shortcomings of MacTCP had to do with so-called "partially
qualified domain names". Suppose I tell the resolver to figure out the
address of a host "mvs"; the old algorithm would see that there are no
periods in it, and would query the nameservers for "mvs.math.niu.edu".
However, there is no such computer. Or if I wanted to contact a host in
another department, and typed simply "mp.cs", MacTCP would send a query
for "mp.cs.math.niu.edu", failing again. A better approach is to strip
away parts of the domain, checking for "mvs.niu.edu" and "mvs.edu" (or
"mp.cs.niu.edu", and "mp.cs.edu") as well. In either case the second try
would succeed.
OT's Domain Name Resolver provides this convenience as follows. The
"Admin domain:" field should contain the fragment of your domain which
you want to append to names if the first query fails. If I enter
"niu.edu" there, both examples given above will work as expected. In
addition, you can specify other domains in the "Search domain names:"
field to extend this mechanism; for example, putting "cs.niu.edu" in it
would let me type simply "mp" to get to "mp.cs.niu.edu". This, of
course, assuming that there is no "mp.math.niu.edu" or "mp.niu.edu"
(otherwise they would be found first).
Finally, many configurations can be saved and loaded through the "File"
menu. You can switch between them without restarting, or edit the
default one (although there is a timeout period of about 2 minutes
during which OT keeps the old settings in its cache).

E.4. Final comments

On a 68xxx Mac, with an application which isn't explicitly written for
OT, there are no direct performance improvements over MacTCP. A 2+ MB
file transferred with Fetch 2.1.2 from a SparcStation 5 to a PowerBook
520 over a lightly loaded Ethernet produced almost identical average
rate of about 85 kbps with both drivers. The speed advantages, if any,
will be seen on a PowerMac with an application using the Open Transport
function calls, because those are native, and would not have to be
trapped by the MacTCP backwards compatibility mechanism present in OT.
However, in my view the new software appears to be much more robust. In
one particular reproducible situation a telnet session to a nearby Unix
host "stutters" and temporarily hangs with MacTCP; the same setup works
like a charm with OT.
I have been using OT on two Macs for about a month with no problems
whatsoever. But keep in mind that both use a direct Ethernet connection,
and both are relatively "clean" (very few non-standard extensions and
gadgets).
One notable omission in the TCP/IP component is that it doesn't seem to
use routing information packets. As we mentioned in Part IV, entering
0.0.0.0 in the "default gateway" field of MacTCP makes it listen to the
network and (usually) discover an appropriate router. My copy of OT
would not do that, whether I entered zeroes in the "Router address"
field or left it blank. Another quirk is that the "Info" button is
supposed to display the software version and the computer's Ethernet
address, and mine did not show the latter.
I also had a problem with the "Use 802.3" button, which is meant to make
the Mac use an Ethernet standard sanctioned by the IEEE committee, as
opposed to the more traditional "blue book" standard developed by 3Com.
One of my Macs would happily work with that setting, while the other one
didn't. This may have been caused by an Ethernet card incompatible with
802.3.
Finally, Open Transport is a memory hog. On the PowerBook with System
7.5 the shared libraries which OT uses take up a lot of RAM, even before
any TCP/IP application starts up; after it does, the System takes up
over a megabyte of RAM more than it does when MacTCP is loaded. This
difference might be less pronounced with the native PowerPC libraries,
but I haven't tried this.

------------------------------------------------------------------------
back to table of contents